Gold Medal Software 3/Gold Medal Software - Volume 3 (Gold Medal) (1994).iso/comms/icom0425.arj/BETA.DOC

Text File | 1994-04-25 | 92KB | 1,728 lines

               Intellicomm v2.01 BETA Release Information
               ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

Please don't press [Esc] until you've read this document!  There are
many changes in the last couple of updates that you need to know about,
and the only way to find out about them is to read this file.  If you're
upgrading from Icom v1, please also make sure you read UPGRADE.DOC which
lists all the changes from v1 to v2.

NOTICE
▀▀▀▀▀▀
This is a BETA release of Intellicomm v2.0!  While it has been tested by
many people for several weeks now, please be aware that bugs and/or
incompatibilities may still exist in the code, and changes are taking
place from one beta release to the next.  If you'd rather not help to
work bugs out of this product, please delete it now and wait for the
general release.

2.01 Beta 6 Notes, 04-25-94
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
■ I went haywire last week and added a HOST MODE to Intellicomm.  A Host
  isn't top priority, but I've had the bulk of the code written for
  months, and it just needed a couple of days of debugging and
  documentation writing.  Please see HOST.DOC for all the details.  Note
  that calls to Intellicomm Host can also be automated by Intellicomm.
  Just use BIF Learn to call the Host the first time, and everything
  will be set up automatically.  An [Icom Host v1.0] template has also
  been included.

■ Transfer Days are now easier to set in the File Tagger, and the split-
  screen report (browse mode) now shows the transfer day next to the
  transfer PRIORITY.  When you select "Priority" now in browse mode,
  Tagger prompts for a priority as usual, THEN prompts for a Transfer
  Day.  If you want to set a specific day of the week to transfer the
  file, just pick the day from the menu.  Otherwise just press [Enter]
  to select "Anyday" (means that it's okay to transfer the file on any
  day of the week).

■ Tagger "Find" / "Find all/Tag all" got caught in an endless loop if
  the catalog was sorted by Filename/File Date or Catalog Date/Filesize.

■ Fixed a bug in Xmodem/Xmodem-1K/Xmodem-1K-G downloads.  If Intellicomm
  started the download before the sender started its upload, the
  transfer was sometimes aborted.

■ When you elected to "Delete" a Call BIFNAME task in the Job Editor, it
  prompts "Delete all jobs for BIFNAME?".  If you answered Yes, the Job
  Editor erroneously removed any "Pause job until", "Repeat job at", and
  "Exit to DOS" tasks that followed.

■ The script MKDIR command was not setting $ERRORLEVEL properly.

■ The script CDATE2DATE and DATE2CDATE commands now set $ERRORLEVEL to 1
  if an invalid date is specified, or set $ERRORLEVEL to 0 if a valid
  date is specified.

■ Other minor fixes.

2.01 Beta 5 Notes, 03-24-94
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Version 2.01 beta 4 was only distributed to Intellicomm registrants who
ordered during the months of January and Februrary.  The major change
from beta 4 to beta 5 is that the online help and the script
documentation are now complete... so you'll probably want to install
beta 5 regardless, even if you have beta 4.  All of the bug fixes and
changes below apply to both beta 4 and beta 5 (in relation to beta 3).

FIXED FROM 2.01 BETA 3

■ IMPORTANT NOTE:  If you're running into any unusual behaviour with
  Intellicomm, such as lockups while running the program or lockups
  AFTER running ICOM.EXE, disable the 'Drop RTS on Disk I/O' option on
  the main setup / Terminal Settings screen.  Please see the online help
  from the Terminal Settings screen for more information.  If that
  doesn't work, and you're using SMARTDRV (the MD-DOS disk cache)
  disable the WRITE BEHIND cache on your hard drive by specifying the
  drive letter after the SMARTDRV command in your AUTOEXEC.BAT file.
  Example: SMARTDRV.EXE C  ['C' assumes your hard drive is drive C:]
  This conflict between SMARTDRV / Drop RTS on Disk I/O only seems to
  occur with the version of SMARTDRV that was included with DOS v6.x.

  The Icom main setup item 'Drop RTS on Disk I/O' now automatically
  defaults to NO.  If you're running a multi-tasker (Windows, DESQview,
  OS/2) and you notice 'Bad CRC errors' during file transfers or other
  communications problems whenever your disk is accessed, try turning
  the Drop RTS on Disk I/O setting back on.  If you then run into
  lockups, the only compromise is to disable the write behind cache on
  SMARTDRV (as mentioned above, specify your hard disk drive letter
  after the SMARTDRV command in your AUTOEXEC.BAT: SMARTDRV C disables
  the write behind cache on drive C), or to use another disk cache.

  Since many people are confused as to what a 'write behind cache' is,
  I'll explain it a bit here.  The 'write behind' SMARTDRV buffer only
  affects disk WRITES, and it INTERCEPTS any disk write attempts, stores
  the data in memory only (the data is not written to disk immediately
  as you would expect).  This affects disk writes that programs try to
  make (to save information) or that you try to make yourself (to save a
  document in your word processor for example).  SMARTDRV then monitors
  your computer for some period of inactivity (assuming it can find
  one... it may not if you turn your computer off after saving something
  to disk) and only when it finds a period of inactivity does it write
  the data from memory (the cache) to disk.  While this does increase
  disk performance, since disk writes can be made in larger "chunks" of
  data ... it can be DANGEROUS if you don't understand the concept,
  since you can lose data if you simply turn your computer off, or press
  [Ctrl-Alt-Del] or Reset (or get a lockup) without WAITING for the
  write behind cache to flush its data to your hard drive.  Apparently
  many people do not understand this concept, and this is why many disk
  caches default to write behind buffering OFF, and force you to turn it
  on (which implies that you know what it is, and thus know how to use
  it).  SMARTDRV used to default write cacheing to OFF, but Microsoft
  decided to default it to ON with the SMARTDRV version included with
  DOS 6.x.  Aside from the above issues, this write behind buffering
  conflicts with Icom's 'Drop RTS on Disk I/O' option (which simply
  lowers the RTS line on the COM port before any disk writes; to avoid
  lost data during disk I/O), though not on all computers.  Symptoms
  include being unable to run any large programs after running
  ICOM.EXE -- if Icom initialized the COM port (which initializes the
  Drop RTS on Disk I/O routine) while it was active.

  Write behind buffering does not affect cache performance for disk
  READS, which is where the most benefit can be gained from SMARTDRV
  (and which Icom has no conflict with).  You can safely use both Drop
  RTS on Disk I/O and SMARTDRV C ... as long as you specify your hard
  drive letter after the SMARTDRV command.  Note that this does not
  affect other disk cache write behind buffers: only SMARTDRV.

■ Many people reported lockups after upgrading Intellicomm, the first
  time (and only the first time) they ran ICOM.EXE.  The problem has
  finally been found and fixed.

■ If TAGGER.INI didn't exist (Icom v1 upgraders only) the ICOM.INI main
  setup file was not converted to v2 format.  This caused ICOM.EXE to
  display the message 'Please run INSTALL.EXE first' even though
  INSTALL.EXE had been executed properly.  ICOM.INI is now updated to v2
  format whether a TAGGER.INI exists or not.

■ There were various hangup problems with beta 3 (endless hangups or
  sometimes not hanging up at all).

■ The debugging log mode 'Extended with buffered disk writes' was
  leaving 'lost chains' on-disk, as the file wasn't always closed prior
  to renumbering.  Renaming an open file causes lost chains.  Further,
  due to the location of the debugging log initialization, the file was
  not always placed in the \ICOM\CAP directory if no D:\PATH\ was
  specified in the Debugging Log Filename main setup option.

■ Auto HS/Link downloads were not disabled during automated downloads,
  resulting in double-downloads (auto-HS/Link carrying out a download on
  its own behind Icom's back before Icom started the [second] transfer
  itself).

■ Finally found the bug in the catalog update routine which is called
  after all automated downloads to Untag files, call POSTFILE.SCR, etc.
  I've known there was a bug somewhere around this area for quite some
  time, but couldn't find it.  The bug was only exposed if using the
  'Export D/L's to TEXT FILE' option (for Sysops) on the main setup /
  File Tagger Settings screen.  It's dead now.

■ If you selected "Note" in the Tagger (and probably "Tag" as well but I
  didn't test for this before I made the fix) to un-Note a noted file,
  all the Transfer Priorities were displayed as '100' thereafter.

■ 'Auto', 'Manual', etc., wasn't displayed on the terminal status line.
  And the script $STAT_ON variable was always set to 0 (signifying
  status line OFF).  Both have been fixed.

■ Time bank transactions were not carried out properly if the account
  was full (deposits) or had no download bytes to withdraw.  If the
  download byte transaction failed, Icom skipped the time transaction.
  Now fixed.

■ The script IF, WHILE and SWITCH commands were not working properly in
  v2.01 beta 3.  Only NUMERIC comparisons were working: text comparisons
  (such as the SWITCH to compare file extensions in POSTFILE.SCR) were
  not working at all.

■ The script $BBS_AREA System Variable was not being set to the proper
  value, nor was it documented properly in the Quick Summary.  $BBS_AREA
  is no longer set to a number but is set to "[L]" (Logon menu or BBS
  main menu), "[M]" (Message Menu), "[F]" (File Menu), "[B]" (Bank Menu)
  or "" (blank if location unknown).  These new values make $BBS_AREA
  compatible with the NEWAREA command, which expects "[L]", "[M]",
  "[F]", or "[B]" to access a given menu or sub-menu.

■ The maximum script variable length (max. length of data stored in
  user-defined variables) and maximum script line length have both been
  expanded from 128 to 256 characters.  The script 'DOS' command,
  however, is still limited to 127 characters maximum.  This limit is
  imposed by DOS itself.  4DOS accepts 255 characters per command, but
  only if the arguments are typed directly on the command line or in a
  batch file.

■ Several script problems relating to the GOSUB command were also fixed.
  If you experienced 'ENDSWITCH without SWITCH' or 'ENDIF without IF' or
  'ENDWHILE without WHILE' errors after using GOSUB, the problem has
  been fixed.

■ This isn't really a 'fix' but more a change: The right mouse button
  can no longer be used in the Terminal to pop up the [Alt-Z] Terminal
  menu.  The mouse was interfering with communications in some cases, so
  it is now disabled in Terminal mode (though you can still use your
  mouse to select items from the Terminal menu after pressing [Alt-Z]).

■ Numerous other minor fixes were made here and there.  In most cases
  only one person ran into/reported the problem(s), and many were in
  little-used areas of the program... so they weren't worth documenting
  here.

ADDED

■ The online help is finally finished!


■ The script documentation (SCRIPT.DOC) is finally finished!

■ BBSTUTOR.DOC and AUTOICOM.DOC have also been included this time.  This
  release contains all the files and features that will be distributed
  in the release version... which I hope to make in a week or two if no
  major bugs show up in this one.

■ Major changes.  I modified the 'edit string' routine so that it can
  now accept more characters than it displays on the screen (i.e. it can
  scroll text within editing fields).  The purpose was to allow you to
  define longer BIF responses and various other things.  Instead of 31
  characters per Custom Command, you can now enter commands up to *150*
  characters long.  And instead of being limited to 20 characters per
  BIF response you can now enter double that per response.

  Job Changes:

  1. The 'Search BBS for files[s]' task now accepts strings up to 80
     characters in length.
  2. The 'Custom Command/Run script' task now accepts strings up to 150
     characters in length, which not only allows much more involved
     tasks to be handled with Custom Commands (with strategically placed
     ^M's, ||, ~~~, etc.: see the online help for details) but also
     allows many more script parameters to be passed when using a
     @SCRIPT command in a Custom Command.
  3. The 'DOS Command/Run a program' task now accepts strings up to 150
     characters in length, again allowing for more command line options
     to be passed to programs/BAT files you run.
  4. The 'Capture on/off' task now accepts strings up to 64 characters
     in length, allowing you to specify a full D:\PATH\FILENAME.EXT as
     necessary.

  BIF Changes:

  1. All BIF responses (any commands Intellicomm SENDS to the BBS either
     in response to a BIF prompt, or to access a sub-menu, search for
     files, get new files lists, etc) now accept up to 40 characters.
  2. The 'Reply Dir' / 'Message Dir' / 'Upload PATH' / 'Download Dir'
     BIF items also now accept up to 40 characters allowing you to
     override the default main setup directories with a much longer
     D:\DIR1\DIR2\DIR3...etc.

  All other BIF items (BIF prompts included) are still fixed at the 20
  character maximum.

■ POSTFILE.SCR has also undergone major changes.  Instead of editing the
  script directly, it now has its own 'main setup' program; POSTINI.SCR,
  which uses menus and so forth to prompt for the POSTFILE settings,
  then stores the settings in a file called POSTFILE.INI.  POSTFILE.SCR
  now gets its settings from this POSTFILE.INI file instead of having
  them hardcoded into the script itself.

  The POSTFILE.SCR setup was simple enough, and required no rocket
  science or real script writing skills to get it working... but the
  setup couldn't exactly have been termed 'user friendly'.  The
  POSTFILE.SCR setup is now much more user friendly, isolating you from
  the script entirely.

  The main reason I made this change was to keep the user-specific setup
  information in a separate file (POSTFILE.INI) so that I can update the
  existing POSTFILE.SCR without forcing everyone to do the setup every
  time.  Now that POSTFILE.SCR contains no user-specific information
  updating the script will be simple.  Another reason the change was
  made was slow startup time: with all the comments and so forth at the
  top of the old POSTFILE.SCR, the script was quite slow to execute on
  some machines.

  If you made no modifications to POSTFILE.SCR other than your setup
  information, the upgrade will be easy and automatic.  But if you
  modified the body of the script itself, this one upgrade could be
  somewhat of a pain. How you handle the upgrade is your choice:
  INSTALL.EXE will rename your existing POSTFILE.SCR to POSTFILE.OLD and
  will install the new POSTFILE.SCR / POSTINI.SCR (which will prompt you
  for your setup information the first time POSTFILE is used).  The best
  course of action would be to then load both POSTFILE.OLD and
  POSTFILE.SCR into a Text Editor capable of displaying/editing two or
  more files, and update the new POSTFILE.SCR with any modifications you
  made to the .OLD (the 'CustomWork' subroutine for example).  But if
  you prefer, you can simply delete the new POSTFILE.SCR/POSTINI.SCR and
  rename POSTFILE.OLD.  Your existing POSTFILE *will* work as it was
  without modification.

■ With thanks to Steve Willer for creating the idea and the routine,
  POSTFILE.SCR can now also use the DESCRIBE command to allow you to see
  the descriptions of newly downloaded files right from the DOS prompt
  using a DIR command!  This option defaults to OFF, but can be turned
  on the first time POSTFILE.SCR executes, for those with 4DOS/NDOS who
  wish to use this feature.

■ A new main setup screen 'Sysop Settings' has been added, and a new
  setting 'POSTFILE.SCR Settings' has been added to the File Transfer
  Settings screen.  The former contains the 'Export D/L's to TEXT FILE'
  and 'BIF Format for Export' items that were previously on the File
  Tagger Settings screen (along with two new options explained below).
  The latter calls POSTINI.SCR which allows you to re-configure the
  user-specific information for POSTFILE.SCR (or to disable/enable
  POSTFILE.SCR).  If you use your -old- POSTFILE.SCR, the new
  'POSTFILE.SCR Settings' option will not work, since all the user-
  specific information was kept in POSTFILE.SCR previously.

■ A BIF template has been added for Spitfire BBS's along with common
  Spitfire bank/message template files.

■ Tagger Tools Import/Export options have been moved to a sub-menu.
  Just select Import/Export from the Tagger Tools to access the options.

■ 'Update DOWNLOAD.NDX' has been added to the Tagger Tools menu allowing
  manual DOWNLOAD.NDX updates when desired.

■ If 'Use DOWNLOAD.NDX' is turned on (main setup, File Tagger Settings)
  Icom now updates the index prior to all automated new files list
  imports.  Previously the DOWNLOAD.NDX update was only done after
  automated downloads.

■ Still more DOWNLOAD.NDX support:  Icom's auto-download routine now
  ignores Tagged files that exist in the DOWNLOAD.NDX (DOWNLOAD.NDX
  holds the filenames of all previously downloaded files if you're
  wondering).  Further, if you Tag a file that exists in DOWNLOAD.NDX,
  Tagger now warns you and allows you to cancel the Tag.  If you proceed
  with the Tag the filename is removed from DOWNLOAD.NDX to allow the
  auto-download routines to re-download the file.

■ A new option 'Auto Tag Remaining Files?' has been added to the main
  setup 'Tagger Keywords' screen.  If Auto Tag Remaining Files is set to
  YES, Tagger automatically tags all newly imported files.  A 'newly
  imported file' is a file that (a) doesn't exist in DOWNLOAD.NDX
  (previously downloaded files); (b) doesn't exist in the catalog
  already; (c) wasn't excluded by the Exclude File Keywords; (d) wasn't
  "noted" by the Note File Keywords.  I.e. all files that would normally
  be UNTAGGED are instead automatically TAGGED for download if Auto Tag
  Remaining Files is turned on.  Great for Sysops: turn this option on,
  and Icom will collect all new files that you haven't downloaded
  previously, and that don't exist on your 'Exclude' or 'Note' keyword
  lists.

■ Support for Sysops:  A new main setup option 'Export by ID/Conference'
  has been added to the new 'Sysop Settings' screen.  If this option is
  turned on, Intellicomm ignores the 'Export D/L's to TEXT FILE'
  filename and instead exports files by BIF ID / conference.  For
  example, if you auto-download two files using a BIF called JOESBBS;
  the first file from conference 0 and the second from conference 1,
  Icom would export the file records (filename, size, date, description)
  to:

   \ICOM\LST\JOESBBS.0
   \ICOM\LST\JOESBBS.1

  You can then append these files to the proper conference file listing
  for your own BBS.

■ More support for Sysops: Another 'Sysop Settings' main setup option
  has been added: 'Move files to Subdir'.  This option allows you to
  define a D:\PATH\ in which Intellicomm will create subdirectories
  based on the BIFID/conferences it downloaded files from, and then move
  newly downloaded files into separated subdirectories.  For example if
  you defined E:\TEMP in this option, and Icom downloaded the following
  files:

   E:\ICOM\GET\FILE1.ZIP   [From JOESBBS, conference 0]
   E:\ICOM\GET\FILE2.ZIP   [From JOESBBS, conference 1]

  ...Icom would create directories (if necessary) and move the files to:

   E:\TEMP\JOESBBS\0\FILE1.ZIP
   E:\TEMP\JOESBBS\1\FILE2.ZIP

  [The Subdir defined in 'Move files to Subdir', the BIFID, then the
  conference the file was downloaded from are used to create a
  subdirectory name.]  You can then operate on the files separately,
  grouped by the BBS's and conferences Intellicomm downloaded from.
  Note that the files are moved AFTER POSTFILE.SCR has done its virus
  checking, so only files that are virus free are moved.  Note also that
  in order to perform a MOVE (instead of a very slow COPY) the 'Move to
  Subdir' directory must be on the same DRIVE (D:) as your Intellicomm
  download directory.

  Don't set up any .BAT files to automatically handle new downloads,
  until you perform an auto-download or two and are 100% positive of the
  subdirectory names Intellicomm moves the files to.

Script Changes
▀▀▀▀▀▀▀▀▀▀▀▀▀▀
The rest of the changes have to do with scripts.  Skip down to the beta
3 notes if you're not interested in scripts.

■ As mentioned earlier, all the script documentation is now complete!

■ A new script command CAPSTAMP has been added.  This command (which
  takes no parameters) stamps the same type of header that Icom itself
  stamps:
==<< YY-MM-DD HH:MM:SS BIFID - BBS Name >>============================

  in the current capture file (if open) and if *capstamp (the main setup
  option 'Stamp Date/Time Cap Open' is on.

■ The script STRITEM command has been enhanced, but since STRITEM
  previously was not documented... it won't matter to you unless you
  figured STRITEM out on your own.  The SUMMARY is now:

  STRITEM vITEMBUFFER sSEARCHSTRING nITEMNUMBER [sITEMSEPARATOR]

  [sITEMSEPARATOR] is a new (optional) parameter.  If sITEMSEPARATOR is
  omitted, spaces, tabs and semicolons serve as the default item
  separator, and spaces/tabs/semicolons enclosed between single or
  double quotes (' or ") in sSEARCHSTRING are ignored.  If
  sITEMSEPARATOR is specified, spaces, tabs and semicolons are ignored
  and only sITEMSEPARATOR serves to separate one item from another in
  sSEARCHSTRING.

■ The STRLEN command now takes an optional position in sSTRING to count
  from.  The new summary is:

   STRLEN vLENGTH sSTRING [nPOS]

  If nPOS is omitted, 0 is assumed (counts the number of characters from
  the beginning of sSTRING).  If nPOS is specified (0 being the first
  character in sSTRING) the count is done from nPOS onward.  The nPOS
  parameter will normally be used after obtaining the position of a
  given character with STRCHR, STRCHRI, etc.


2.01 Beta 3 Notes, 12-24-93
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

NOT FIXED

■ There was a bug (several bugs over the course of the v2 testing
  actually) that caused your catalog indexes to misrepresent the data in
  your Tagger catalogs.  You can fix any previous problems before using
  this update for the first time by deleting all your Tagger index files
  with the command:

   DEL \ICOM\DBF\*.NDX

  Note that this does NOT destroy the catalogs themselves: Tagger will
  rebuild the indexes automatically the first time the catalog is
  accessed.  [Does not apply to \ICOM\DOWNLOAD.NDX; you needn't delete
  that file.]

■ There may still be a bug in the File Tagger, or in another area of
  Intellicomm that affects File Tagger catalogs.  Three catalog-related
  problems were reported with v2.01 beta 2 and a couple of fixes were
  made (see below) but I have as yet been unable to reproduce most of
  the v2.01 Tagger-related problems.  If you do run into a problem with
  the File Tagger, please attempt to recall exactly what you did (see
  the \ICOM\CAP\ICOM.DBG debugging log to refresh your memory) and try
  to reproduce the problem before reporting it, if possible.  If you
  cannot reproduce the problem yourself, chances are I won't be able to
  reproduce it either, and very little can be done about problems that
  cannot be reproduced.  I've already looked all the code over many
  times and have come up empty, so whatever it is (or was) it's not
  going to be easy to find without detailed information.

  If you do run into a problem, access the Icom main setup, switch to
  the "Debugging Log Settings" screen and set the debugging log to
  "Extended with Buffered Disk Writes".  This will write very extensive
  debugging information in the debugging log, which you can then post in
  your message to me to show me exactly what Icom did.

FIXED FROM 2.01 BETA 2

■ If Icom took a long time to start on your system, and took a long time
  to perform DOS shells, etc., the problem should now be much less
  severe.  Some mouse drivers take extended periods of time to perform a
  mouse 'reset' and this is what causes the delay ... but that was only
  part of the problem.  Intellicomm was performing this 'reset' up to
  SIX times in some circumstances and that problem has now been
  corrected and only one reset is performed, when a reset is necessary.

■ Another Tagger bug was fixed, though just what effect the bug had is
  hard to determine.  Even explaining the problem in general terms is
  difficult...  The only way I was able to locate it was via a detailed
  report from a user: Hilight a Tagged or Noted record that had a
  Catalog Date older than the View Date (keeping in mind that the View
  Date is ignored when it comes to Tagged/Noted records)... then Untag
  the file (or pick "Untag" to Untag all tagged/noted files).  Tagger
  tried to 're-hilight' the same file after the untag, but couldn't
  because it was no longer visible.  This led to errors (nothing would
  be visible at all, and Tagger would display "File Num 0 of 0" in the
  bottom display) and perhaps even catalog corruption as various flags
  and variables ended up out of whack after such an occurrance.

■ If an invalid date crept into one of your file catalogs (corruption
  from a previous bug being the most likely reason... perhaps even due
  to the bug listed above) the catalog became all but unuseable: The
  index rebuiding routines gave up when they found an invalid date, and
  that was the end of the catalog: no indexes, and no way to rebuild
  them, means no catalog.  Now the index rebuilding routines check for
  this error and correct it by writing today's date in the corrupted
  database record.  You should then at least be able to get into the
  catalog where you may see a record full of garbage (except for the
  dates) and you can then delete the corrupted record and pack.

■ After Tagger imports, either automated or manual, the next file
  Tagged/Noted was not updated properly in the indexes.  If using the
  Tag Status/Location sort order, Tagger would display "Record re-
  sorted" but the record was not re-sorted to the top of the catalog and
  remained where it was... and from that point on, your indexes were out
  of whack with the database information, leading later to "Key not
  found" errors and possibly other problems.

■ The menu which asks whether to install ICOMAUTO.ZIP (an auto-BIF
  downloaded from a BBS) was not displayed properly.

■ Many other minor fixes were made that are too obscure or too minor to
  document.  If you ran into a problem previously and it no longer
  exists, that's the documentation of the fix.

The rest of the FIXES relate to scripts.  Skip down to the ADDED section
if you aren't interested.

■ The script VGETCHRS command (get characters from the video screen) was
  not working properly.

■ Script WAITFOR commands had difficulty if Icom was running under a
  multitasker (DESQview, OS/2 or Windows).  Time slices were released
  too rapidly resulting in very slow terminal updates during a WAITFOR.

■ A further problem was also found with WAITFOR that forced a change
  which may affect your existing v2 scripts.  If many characters were
  piled up in the Icom Receive Buffer when WAITFOR was executed, it was
  possible for the text WAITFOR was waiting for to be missed.  This was
  due to the fact that WHEN and WAITFOR were using different methods to
  match text from the terminal.  The details are too boring to go into,
  but what I had to do to solve the problem was take one of the WHEN
  slots and use it to track the WAITFOR text.  This doesn't affect how
  WHEN/WAITFOR work together from a script writing point of view, it
  simply means that you now have one fewer WHEN to work with than you
  did previously: 19 WHENs and not 20.  If you have written a script
  that uses all 20 of the WHEN slots you'll have to now accomplish the
  task either by handling two prompts with one WHEN (if you can find
  common BBS text in two prompts and common responses are sent to both
  prompts) or by splitting the task up into two pieces and using WAITFOR
  earlier than you did previously.

ADDED

■ A new main setup screen: "Debugging Log Settings" which allows you to
  define the debugging log 'level' (either Normal or Extensive; more
  below), the filename used (for possible RAMDisk use when in EXTENSIVE
  mode), and the number of backup logs to keep on hand.  Previously only
  one "back issue" of the debugging log was kept, but this proved to be
  insufficient and now, by default, 4 back issues are kept (5 files
  total including ICOM.DBG itself).

  The new EXTENSIVE debugging log level, which is turned on via the new
  "Debugging Log Settings" main setup screen, has two modes: Immediate
  Disk Writes and Buffered Disk Writes.  Immediate Writes should be used
  when you have a problem which involves a lock up.  Buffered writes
  should be used to gain detailed information when there's no
  possibility of a lockup.  If you report a problem and I need further
  information, I'll recommend one of the two Extensive log levels based
  on the situation.

  For more information regarding the new Debugging Log settings, access
  the Icom main setup, select "Debugging Log Settings" and press [F1]
  for detailed online help.

■ You can now press [Up] / [Down] (cursor arrow keys) to adjust the
  priority after selecting "Priority" in the Tagger.  [+] and [-] still
  work as well.

■ When you delete a file (browse mode "Del" option) the File Tagger now
  checks on-disk for the file: first in the directories listed on your
  'Upload PATH' then the Download Directory (\ICOM\GET), then in all the
  directories on your DOS PATH (if "Use PATH to Locate files" is turned
  on, in the main setup General Settings screen).  If the file is found
  you are asked whether to delete the file on-disk as well.

2.01 Beta 2 Notes, 12-15-93
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

FIXED FROM 2.01 BETA 1

[Not many people had a chance to try v2.01 Beta 1 as it was a very
short-lived release.  If you didn't try it, skip to the 2.01 beta 1
notes just below which detail v2.00 beta 3 fixes.]

■ No less than three bugs were located in the post-job processing
  routines, which include everything from running POST*.BAT to updating
  Tagger Catalogs.  Explanations of the bugs would be meaningless even
  to other programmers, but suffice to say that if you ran into problems
  any time after running a job, or even after exiting Intellicomm when
  starting another program, you are three times less likely to run into
  problems now.

  These bugs were also the cause of many strange happenings from lockups
  to endless Print Screens, after using [Alt-Q] / Abort Job (switch to
  manual by aborting the job).  I had thought this problem was fixed
  with v2.01 beta 1 but it was not.  Just after the release of 2.01 beta
  1 I finally found a reliable way to reproduce lockups after switching
  to manual and was thus able to re-test after fixing the bugs, and
  VERIFY that the problem had been fixed.  It's definitely fixed.

■ There was a bug in the 2.01 beta 1 File Tagger catalog conversion
  routines that locked up some machines on new installations.  I was
  unable to reproduce a lockup during or after catalog conversion, but
  did eventually locate a bug in this area and fixed it.  Hopefully it
  was 'the' bug that was causing lockups on some machines.

2.01 Beta 1 Notes, 12-09-93
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

FIXED FROM 2.00 BETA 3

■ Usage Stats, displayed at the Main Menu, were being corrupted somehow.
  I have no idea as yet what caused the problem, but more than one
  person reported corrupted Usage Stats.  More than likely, one of the
  bugs listed below (or above) was corrupting memory, but as I have no
  indication as to what caused the problem I can't be sure that it's
  fixed.  Until the problem is located I've added a Main Menu option to
  reset the stats.  The option is not visible: just press [Ctrl-S] from
  the Main Menu and all your stats will be reset to zero.  Please let me
  know if you run into corrupted stats again with v2.01, and, if
  possible, attempt to recall what you did with Intellicomm before the
  stats were corrupted.  If you press [Ctrl-S] to reset your stats to
  zero, then can REPRODUCE the corruption through a certain set of
  events, we'll have this problem fixed very quickly.

■ There was an error in the Windows Setup documentation (online help).
  You were instructed to set all the COMxBuffer= settings to ZERO, and
  while this solves problems on some machines, and also bypasses a
  Windows bug, it can CAUSE problems on other machines, particularly if
  a 16550 UART is not in use.  If you're having problems running
  Intellicomm under Windows (lost characters and/or file transfer
  errors) change the appropriate COMxBuffer setting in your
  \WINDOWS\SYSTEM.INI file to:

  COMxBuffer=8192

  ['x' being the COM port Icom uses; e.g. COM2Buffer=8192].  The Windows
  online help topic (see "Multitasking Intellicomm" from the Help Index)
  has also been revised for v2.01 with some further tips that may be of
  interest if you're having problems with Icom under Windows.

■ Whether a 'fix' or a new feature, I think we have finally arrived at a
  proper solution for COM port access and modem initialization.
  Starting with v2.01 beta 1, the COM port isn't touched and the modem
  isn't initialized at program startup.  Modem initialization (by
  default) takes place as with Icom v1.00, just before accessing the
  dialer/terminal for the first time.  Further, the COM port is now
  returned to its original state when not in use, if Icom is offline.  I
  was able to program this in such a way that we lost none of the
  benefits of v2.00 (i.e. the contents of the scrollback buffer/terminal
  screen remain intact if you switch out of the Terminal while online,
  which was not the case with v1.00) and gained back all the benefits of
  v1.00 as far as COM port use and modem initialization.  Further, a
  switch has been added to the main setup "General Settings" screen
  allowing you to force Icom to initialize the modem at program startup,
  if you run into dialing problems due to this change.

■ Again a new feature which may end up to be a fix on some systems; a
  new switch has been added to the main setup / General Settings screen:
  "Drop RTS on Disk I/O".  If set to Yes, Intellicomm re-vectors
  interrupt 13h (the BIOS vector for disk input/output) to point to a
  little routine which simply lowers the RTS (request to send) line on
  the COM port, if the port is open, then calls the original BIOS vector
  to perform the disk I/O, then raises RTS.  While RTS is dropped,
  modems that support CTS/RTS flow control will not send data to the
  computer.

  Most communications programs and external protocols DO drop the RTS
  line for disk activity (or have an option for it), since characters
  from the COM port can be lost during disk I/O if RTS isn't lowered.
  However, most programs do NOT re-vector interrupt 13h... they simply
  lower RTS in their own disk write routines, which means that if you
  use a disk cache with a write behind buffer (delayed disk writes) the
  timing is thrown off and the RTS protection is useless.  Intellicomm
  avoids this problem by capturing the CACHE activity (via interrupt
  13h) whenever disk reads/writes actually take place.  It's much more
  reliable to handle it this way -- but given the strange problems with
  v2.00 I decided to include a switch to allow you to shut this feature
  off, simply so we can eliminate this feature as the possible cause of
  lockups during or after running Intellicomm.  Thus, if you do run into
  problems with v2.01, shut this switch off and see what happens.  Most
  likely it will have no effect, but if it DOES, and the problems go
  away, please let me know.

■ Intellicomm's terminal and timer routines have been optimized and
  streamlined, significantly reducing overhead.  Performance
  improvements will be most noticeable on slower computers with fast
  modems.  Protocols will most likely show no differences; this affects
  only the terminal.

■ Due to a change in this release, you're now much, MUCH better off NOT
  swapping Icom out of memory when calling external protocols.  By
  default, Icom doesn't swap itself out when calling external protocols,
  since it wastes time swapping Icom back IN and re-initializing the COM
  port after the external protocol finishes; which can cause missed
  'Transfer Successful' messages from the BBS.  There's absolutely no
  need now to swap Icom out of memory when calling external protocols,
  unless the protocol won't load due to a lack of memory.  Thus you
  should remove any SW: (SWap) prefixes in the main setup/External
  Protocols menu:

  ║  1.  DSZ-Zmodem          D    SW:DSZ-D.BAT     SW:DSZ-U.BAT    No  ║
                                  ───              ───
  Change to:

  ║  1.  DSZ-Zmodem          D    DSZ-D.BAT         DSZ-U.BAT      No  ║

■ I believe the hangs and other problems that occurred just after
  Intellicomm disconnected in manual mode, have been fixed.
  Unfortunately I was unable to reproduce the problem at will, so there
  was no way to confirm 100% that the problem was fixed.  I found some
  coding problems and made a fix, but whether it was 'the' fix I won't
  know until I hear back from you.

■ Beta 3 was the first release of Intellicomm to become both Windows and
  OS/2 aware (v1.00 was already DESQview aware).  "Aware" meaning that
  Icom will detect the type of operating system at program startup, and
  will give "idle" time back, avoiding a needless waste of processor
  time when Icom is idle.

  However, apparently beta 3 was being a little TOO generous and giving
  back so much time that file transfers wouldn't start properly
  (particularly uploads), and in one case it took Icom 30 seconds just
  to respond to a BBS prompt.  I made a number of changes and believe
  this is fixed now.  If you run into problems with v2.01, see the note
  in the "Added" section below (the new "Release Time Slices" main setup
  option), and please drop me a note reporting your findings.  I'll be
  particularly interested to know whether shutting off Release Time
  Slices setting mentioned below fixes the problem for you.

■ Max. Online Time defined in each BIF was not working.  If an automated
  run went past the max. time, Icom would display a message stating that
  the maximum online time had elapsed, but would cancel the job WITHOUT
  logging off the BBS.  Fixed.

■ Reports of file dates and/or times that were erroneous (4 hours off,
  etc) in v2.00 beta 3 are not Intellicomm's problem.  I tested a
  computer-to-computer link up where the file date/time was known on the
  remote computer, sent the file with DSZ Zmodem, received with Icom's
  Zmodem (then Telix's, then Qmodem's, then with DSZ), and the file
  date/time was right on the money.  If you get improper file
  dates/times, it's either due to a bug in the SENDING protocol (not
  adjusting to Greenwich Mean Time [GMT] as required by the Ymodem and
  Zmodem specifications) or the fact that you're in a time zone other
  than Eastern Standard Time (EST) which is what Intellicomm defaults to
  in lieu of a time zone variable.  Outside the Eastern Standard Time
  zone, you must set the 'TZ' (Time Zone) environment variable in your
  AUTOEXEC.BAT specifying your time zone.  Note that many other
  protocols/comm. programs will also make use of this variable when
  transferring files:

     SET TZ=PST8PDT

  The above says your Time Zone is Pacific Standard Time, 8 hours
  westward from GMT (negative numbers adjust eastward from GMT), and
  that the zone follows "Daylight Savings Time".  The actual letters
  used (PST, PDT) are irrelevant; to Intellicomm at any rate.  Any 3
  letters followed by the number of hours west (positive number) or east
  (negative number) your area is from GMT (0 to +12 -12 hours) is
  acceptable.  If you follow that by any 3 letters (the PDT above), it
  is assumed that your time zone follows Daylight Savings Time.  Whether
  DST is actually in *effect* is irrelevant: Icom will figure that out
  based on the current day of the year, and your time zone.  So, if
  you're in Sydney Australia, add SET TZ=XXX-10XXX (10 hours east) to
  your AUTOEXEC.BAT; in Rio De Janeiro SET TZ=XXX3XXX (3 hours west), in
  Newfoundland SET TZ=XXX4 (no XXX following since Nfld. doesn't follow
  Daylight Savings Time).

  This problem is not unique to Intellicomm, and the same problems occur
  with any external protocol, communications program or BBS; since DOS
  has no idea which time zone you're in ... and Zmodem's designer
  decided to pass file dates/times, as the number of seconds since
  January 1st, 1970, Greenwich Mean Time.  Thus, Intellicomm (any
  receiving Ymodem or Zmodem protocol) must ADJUST that Jan 1st, 1970
  GMT time back up to the proper time for your time zone.  Again, it's
  quite possible that some Zmodem implementations and/or the TZ (or
  ZONE= for DSZ) variables on *BBS's*, are not adjusting file times to
  Greenwich Mean Time as they should.  If you've never heard tell of
  this issue before... you're not alone.  Many Sysops haven't heard of
  it either, and if either the BBS, or the Zmodem implementation AT the
  BBS doesn't adjust to GMT properly ... or your system doesn't adjust
  FROM GMT properly due to no 'TZ' variable, you'll end up with
  erroneous file dates/times on Ymodem and Zmodem downloads.

■ 'Add line feeds' was not being turned on automatically in Chat Mode,
  causing the remote's lines to overwrite one another.  Fixed.

■ Icom's internal screen blanker is now temporarily disabled while you
  are in Chat Mode ([Alt-T] from the Terminal).

■ Have you noticed your BIF Logon Passwords going "missing"
  periodically?  The cause has finally been found and fixed.  If you
  hilighted a BIF that contained a Logon Password and selected "Create"
  to create a similar BIF... the password in the original BIF was lost
  every time.

■ When the BIF Editor's "Merge" option was used, the computer would lock
  up after exiting the BIF Editor.  Fixed.

■ Tagger fixes:  Your existing catalogs will be completely rebuilt when
  2.01 beta 1 accesses a catalog for the first time.  If the rebuild
  fails (unless due to lack of disk space for the rebuild), you'll have
  to delete your catalogs and start from scratch, or restore your v1.00
  catalogs.  Many Tagger enhancements and changes have taken place from
  beta 3 to 2.01 beta 1.  Please read on.

■ If you tagged a file using anything but the Tag Status/Location sort
  order, and were near the bottom of the catalog, Tagger would lose its
  place and would start re-displaying files from the TOP of the catalog
  if you pressed [Down] or [PgDn].  Fixed.

■ A major re-organization of the File Tagger code has taken place, to
  thwart "Key not found" errors, which can lead to index corruption and
  even duplicate index keys (two keys pointing to the same record,
  making it appear as though duplicate records exist in the catalog).
  Key not found simply means that one or more index (.NDX) files are out
  of whack with the data in the database (.DBF).  But they can also
  occur if Tagger saves its position in the index prior to Tagging a
  file, for example, then attempts to restore that position (find an
  index key that no longer exists due to the fact that the Tag Status
  has changed).  It's an unusually complicated affair to keep everything
  straight under every possible circumstance, simply due to the way that
  dBASE indexes work... but I spent more than a few days going over the
  code and re-organizing it, adding double-checks and so forth, and I
  tested everything I could think of without running into any further
  problems.  But please be aware that it's extremely difficult to test
  every possible circumstance the Tagger could run into, and that
  problems may still exist... and due to the number of changes made, as
  careful as I was, new bugs may even have been inadvertently introduced
  in other areas.  However, due to the re-organization that took place,
  any future bugs should be much easier to locate and fix.

■ If you Noted a TAGGED file in the Tagger, it was untagged instead of
  being noted.  Fixed.

■ The way capture "stamping" occurs has been changed (meaning the line
  you see in the .CAP files reporting date/time of connections).  I
  moved the stamping routines to another location, outside of the usual
  "open capture file" routines.  This means that unless Icom opens the
  capture file itself ("Open Capture on Connect" main setup option), the
  line will not be written to the capture file.  This change was made to
  avoid double-stamps in the capture file, and is mainly of note to
  script writers who used the CAPTURE command.  CAPTURE, when called
  from a script (or via [Alt-L] from Terminal Mode) will no longer stamp
  the line in the capture file when called.  Previously if you (or Icom)
  simply closed and opened the capture file, you'd end up with a new
  capture stamp each time.

■ The "Search" option in the online help wasn't searching SCRIPT.HLP
  (script information) or ADDON.HLP (add-ons, Multitasking Intellicomm)
  correctly.  For example, if you searched on the string "OS/2", none of
  the help topics discussing OS/2 were searched in ADDON.HLP.  Now
  fixed.

■ Job items 'Change BBS/File Areas' and 'Get new files list' were not
  working properly together and v2.00 would re-join the default file
  conference (as specified in the BIF) prior to each new files scan.
  Now the default conference is only joined if a 'Change BBS/File Areas'
  task is not used prior to the new files scan.

■ HS/Link mail transfers are now working (HS/Link is a popular bi-
  directional external protocol available as shareware on many BBS's).
  Previously Icom passed the mail packet filename to HS/Link instead of
  the REPLY packet filename, which resulted in replies not being sent
  bi-directionally while the mail was downloaded.

■ HS/Link auto downloads are now more reliable.  Previously Intellicomm
  watched for only two characters of the HS/Link auto-download sequence.
  It now watches for four characters (as outlined in the HS/Link
  documentation), reducing the possibility of random garbage after
  aborted file transfers to start (or re-start) an HS/Link download.

■ The script DIAL command was not working in any circumstance other than
  DIAL "".  It now works as advertised (see SCRIPT.DOC).

■ The script WAITFOR command was not jumping to the timeout label if the
  waitfor string was not found in the specified timeout period.  Fixed.

■ The script GOTO/GOSUB *label ('label' being a variable holding a label
  name) syntax was not working.  Fixed.

■ Various other script problems were also fixed.  Drop me a note if you
  find any more problems.

ADDED [2.00 TO 2.01]

■ "Release Time Slices?" main setup option on the General Settings
  screen allows you to control whether Intellicomm releases time slices
  to DESQview, OS/2 or Windows while online (Icom always releases time
  slices while idle, if offline).  Releasing time slices means that when
  no COM port input/output, keystrokes, or mouse clicks are pending,
  Icom will release the remainder of its time slice back to the
  operating system, allowing smoother performance of other 'open'
  applications.  Basically it means that Icom won't hog your system as
  most DOS applications do... when it doesn't HAVE to hog the system to
  process hundreds of events such as COM port interrupts.  However, if
  you experience missing characters in the terminal while online, and/or
  excessive file transfer errors, you might want to shut this option
  off.

  Scripts can also control the Release Time Slices setting by accessing
  the main setup tag '*rslice'.  On/off, as with all flag-type variables
  is signified by zero (off) or non-zero (on).  Example:

  assign *rslice 0   ;do not release time slices online
  assign *rslice 1   ;release time slices online

■ NEW TAGGER ENHANCEMENTS:  "Stubborn" tags have been introduced, as
  well as file transfer priorities, and smarter Noted file sorting:

  You can now set "Stubborn" tags via Tagger Edit mode (hilight the file
  in browse mode and pick "Edit").  Stubborn tags remain tagged until
  the file is successfully downloaded.  I.e. if the BBS reports "File
  not found" Icom keeps it tagged and tries again next time, until the
  file is successfully downloaded or manually untagged.  You could also
  set a "Transfer Day" (again in Tagger Edit mode) with the Stubborn Tag
  so that Icom would only try for the file on Fridays, etc., if you
  desire.  This will be handy when you see something interesting being
  discussed, and you have the filename... but you don't know if the file
  exists on the BBS you call yet.  Just "Add" the filename to your
  catalog manually, set a Stubborn Tag, and Icom will repeatedly attempt
  to download the file until it shows up at your BBS and is successfully
  downloaded.

  File Transfer Priorities (shown in Edit mode as either "U/L Priority"
  or "D/L Priority" depending on the catalog you're viewing) allow you
  to tell Icom how to transfer files, by entering an optional priority
  number from 1-200 (1 being top priority), either in Edit mode or by
  selecting "Priority" from the browse mode bottom menu.  The default
  priority for every file in your catalogs is 100 (this is done during
  the conversion mentioned above)... which puts every Tagged file
  'equal' right in the middle of the priority scheme.  So if you saw one
  or two files you wanted to transfer immediately, all you'd have to do
  is set the priorities on those files BELOW the 100 default (priority
  10, priority 20, etc).  If you saw one or two huge files you DIDN'T
  want to download until later, all you'd have to do is set priorities
  ABOVE 100 (110, 120, etc) to sort them after the default of 100.
  Files can also have the same priority, so you needn't use priority 10,
  20, etc., unless you really want to have complete control over every
  file that Icom transfers.  If you like, just set the files you want
  immediately to priority 1, the files you don't really care about to
  priority 200 and you're done.  Again, the priorities are optional.
  You don't have to set priorities for any files if you don't want to...
  If you don't, Icom will just download them sorted by filename as
  usual.  For a full explanation of this new feature, along with several
  tips and examples, select "Priority" in the File Tagger (on a Noted or
  Tagged file), then press [F1] and read the online help.

  Smarter Noted File Sorting: The ability to set sorting priorities for
  individual records also allowed an enhancement to the way Noted files
  are sorted.  If you Note a file manually, its priority (only of use
  when using the Tag Status/Location index which takes the priorities
  into account) remains set at 100.  If a file is noted automatically by
  Icom due to a match in the "Note Keywords" list on imports, priority 1
  is set for the 1st keyword on the list, 2 for the second, etc.  So,
  for example, if "Windows" was the first keyword on your Noted Keywords
  list, all the files containing the word Windows in the file
  description would be sorted to the top of the catalog (if you use the
  Tag Status/Location sort order), all grouped together... then the
  priority 2 Noted files, etc.  Modify your Noted Keywords list if
  necessary, moving the most interesting keywords to towards the TOP of
  the list, to take advantage of this new feature.

■ The "Column 2" menu item in the File Tagger has been moved to the
  Tagger's Tools menu to make room for the new "Priority" item discussed
  above.  Further, "Tagger Column 2" has been removed from the main
  setup program / File Tagger Settings screen.  Tagger now saves the
  Column 2 status right in the catalog header, when the catalog is
  closed.  Thus, you can now set different Column 2's for each catalog.
  Note that the very first time you access your Catalogs with v2.01, you
  may have to select Tools/Contents of Column 2 to set it the way you
  prefer, since this value is no longer read from or saved to ICOM.INI.

■ You no longer must pick "Select" from the Tagger after selecting BBS's
  to upload to (FILELIST catalog).

■ An "Untag" item has been added to the menu of BBS's displayed when you
  tag a file for uploading in the Tagger.  Thus to completely untag a
  file in the FILELIST catalog, hilight it and press 'T' (Tag), then 'U'
  (Untag) and 'S' (Select) or eXit/Esc.

■ Seven more speeds have been added to the Minimum Connect Speed menu:
  7200, 12000, 14400, 16800, 21600, 24400, and 28800.

■ When a connection is made at a lower speed than the Minimum Connect
  Speed you've defined (either in the main setup or the BIF) Icom now
  displays a menu allowing you to immediately select "Remain Connected"
  or "Hang up Now".  This allows you to hang up without waiting 10
  seconds.  If you select neither, v2.01 defaults to hanging up after 10
  seconds, as with v2.00.

■ You can now run a script to initialize your modem, by specifying
  @SCRIPTNAME as the initialization string in the Icom main setup
  (Terminal Settings screen).

■ Tagged files that are untagged due to an unsuccessful file transfer
  (file not found, etc) are no longer deleted.  Files are only deleted
  from download catalogs once the transfer is successful.

The rest, up to the beta 3 notes just below, regards scripts.  Skip it
if you haven't delved into scripts yet.

■ New script System Variables $CPRIORITY_FLD and $CFLAG_FLD (Tagger
  catalog fields similar to $CTAG_FLD) have been added.  $CPRIORITY_FLD
  allows you to check or set the transfer priority of the current file.
  Example:

  cgetrec
  assign $CPRIORITY_FLD 10   ;set to priority 10 (100 is the default)
  cputrec

  This will only work on either Tagged or Noted files.  Check $CTAG_FLD
  to see whether a file is 'T'agged or 'N'oted.  When using the Tag
  Status/Location sort order (see CSETSORT in SCRTUTOR.DOC), files are
  now sorted by Tag Status, Location, Download Priority (a number from
  1-200, 1 being top priority), file Conference, Filename.  I.e. all
  Tagged files for a given BBS are grouped together, with the highest
  priority file first, the next-highest second, etc.  By simply using
  the Tag Status/Location index and using CGETREC, you'll get all the
  Tagged files in the proper order, according to the priorities the user
  has set.

  $CFLAG_FLD is a general purpose flag in EACH catalog RECORD, that you
  can use as you see fit.  The real length of the 'FLAGS' field (a new
  database field introduced in v2.01) is 5 bytes; you have access to one
  of these bytes from scripts for anything you want.  Icom uses the
  FLAGS field (a portion of it that cannot be accessed from scripts) to
  keep track of file transfer results, and Stubborn Tags.  Each time a
  filename is sent to the BBS during automated transfers, Icom
  increments a counter stored in the FLAGS field.  If the counter goes
  past 3, Icom cancels the transfer (keeping the file tagged), which
  eliminates any possibility that the same filename will be entered over
  and over again forever due to bad BIF setup, errors, etc.  When 'File
  not Found', 'No time', 'No bytes', 'Transfer Successful', etc. are
  received from the BBS, Icom makes another note in the flags field,
  storing 'C' to cancel the transfer (Untag the file), 'S' for a
  successful transfer, etc.

  If you write a script to perform auto downloads, you can put
  $CFLAG_FLD to the same use.  Icom never touches or checks the contents
  of $CFLAG_FLD (the portion that scripts have access to) so you can use
  it as you see fit to keep track of anything that your scripts need to
  keep track of.  The field is set to a blank space (" ") by default,
  and it's good practice to set it back that way when your script is
  done with it.  Example:

  cgetrec 5
  assign $CFLAG_FLD "A"  ;"A" would signify some condition to you...
                         ; maybe that you'd already tried to download
                         ; the file, or that the record should be
                         ; deleted or untagged, etc.
  cputrec

  Later, to check the flag:

  cgetrec 5
  if $CFLAG_FLD = "A" return  ;skip something if flag is set

  And when your script ends:

  cgetrec 5
  assign $CFLAG_FLD " "  ;clear the flag
  cputrec

■ New script System Variable $OPSYSTYPE (a numeric read-only variable)
  allows you to determine which operating system your script is running
  under:  0 = DOS, 1 = Windows, 2 = OS/2, 3 = DESQview.  Example:

  switch $OPSYSTYPE
   case 0
    print "DOS detected."
   endcase
   case 1
    print "Windows v3.x detected."
   endcase
   case 2
    print "OS/2 v2.x detected."
   endcase
   case 3
    print "DESQview detected."
   endcase
  endswitch

  Windows versions lower than v3.00 and OS/2 versions lower than v2.0
  are ignored and will be reported as DOS (0).

2.00 Beta 3 Notes, 09-22-93
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
■ IMPORTANT: This should probably go in the "ADDED" section, but it's
  important and I don't want anyone to miss it.  Icom v2 has become both
  Windows and OS/2 aware starting with beta 3 (it was already DESQview
  aware, since v1.00) and it will give its time slice back to either
  DESQview, Windows v3 or OS/2 v2 when nothing is going on (no
  keystrokes, mouse clicks or COM port activity).  The goal is to make
  Icom run smoother in the background, while you're doing something else
  in the foreground, and with what testing I was able to do I'd swear
  there was a noticeable improvement; but I'm not a big Windows user,
  and am very short in time right now, so I wasn't able to do any
  'definitive' testing before releasing beta 3.  And I don't have OS/2
  period.... nor a high-speed modem, so whether this will end up causing
  Bad CRC's or other errors at high speed, I don't know.  If it does,
  I'll have to remove this new "awareness", since v2's release must be
  made as soon as possible.

  Please let me know how you make out with this; whether you notice an
  improvement while Icom is running in the background and/or whether you
  experience transfer errors, etc... or whether you notice no change at
  all.  <grin>

DONATIONS

Thanks to all who sent a donation/voluntary upgrade in support of
Intellicomm v2.0!  You got me out of a very serious financial bind last
week, and Intellicomm v2 would (at best) have been delayed for a month
or more without your help, or (at worst) could have been history.  If
you made a donation or have purchased Intellicomm v2 recently, thanks
again!  You're a wonderful group of people.

FIXED FROM BETA 2

■ Running into hangs with Icom v2 either during or AFTER running
  ICOM.EXE?  Please remove SMARTDRV (Microsoft's disk cache) from your
  CONFIG.SYS or AUTOEXEC.BAT and see what happens.  Several people
  solved some very strange problems by dropping SMARTDRV and switching
  to HyperDisk (a better/faster Shareware disk cache, available on most
  BBS's), or basically using any disk cache OTHER than Microsoft
  SMARTDRV.  I intend to find the conflict of interest between Icom v2
  and SMARTDRV, but in the interim please use another disk cache.

■ The new Minimum Connect Speed feature connected to each BIF (see beta
  2 notes below) would hang your machine (or do even stranger things, eh
  Eric?  <grin>) if you set it TWICE before exiting the BIF Editor.
  Actually it could have hung under different circumstances as well, but
  the root problem is now fixed.

■ Not only that, but the Minimum Connect Speed wasn't working in beta 2!
  It now works as it was supposed to.

■ If the connection was lost during an automated download, Icom did call
  back, but didn't re-start the batch where it should have been started
  -- on the file that was being transferred when the connection was
  lost.  I'm not 100% positive that this is fixed under every possible
  circumstance, but everything worked with beta 3 on lost connections in
  the tests I ran.  If you do run into this again in the future, please
  let me know the circumstances surrounding the problem: a clip from the
  ICOM.CAP file posted in your bug report, showing the entire auto-
  download process (what did work as well as what didn't) will be
  necessary.

■ I don't know if anyone ran into this, but it was possible for Icom to
  upload a file to a BBS even though there was no "Upload Pending:" for
  a given BIF ID.  The only time the problem occurred is if a file had
  already been uploaded somewhere (i.e. an "Uploaded to: ANYBIFID"
  existed), and was subsequently Tagged again for upload to another BBS.
  In such a case, the file was uploaded to any/all BBS's that had an
  "Upload tagged files" task.

■ Whether a previous bug or a "new feature": The status line is now
  automatically turned OFF when you activate doorway mode with [Alt-=].
  The real DOORWAY program doesn't use a status line, and thus some
  doors that do support doorway mode assume that they have the entire 25
  lines of the terminal screen to work with.  The status line is
  automatically turned back ON (if it was on previously) when doorway
  mode is toggled off with [Alt-=].

■ Before calling POSTFILE.SCR / POSTFILE.BAT, Icom writes each newly
  downloaded file's description to \ICOM\FILE_ID.DIZ, to allow access to
  the file description from POSTFILE.BAT and to allow you (via
  POSTFILE.SCR or POSTFILE.BAT) to add a FILE_ID.DIZ to archives that
  don't have one included.  However the file description was not re-
  formatted properly before writing to FILE_ID.DIZ.  The description is
  now re-formatted to 40 characters per line maximum.

■ Tagger's "Untag" option is finally working, for both Tagged and/or
  Noted files.  I documented a "fix" in beta 2, but as it turned out it
  wasn't fixed at all.

■ The right mouse button was supposed to Note files in the Tagger, if
  you right-clicked on a file in the upper browse mode window.  And a
  right-click did actually Note the file, but it didn't DISPLAY the "»"
  Noted status.

■ The new "UART:" stat on the [Alt-P] menu wasn't displayed on the same
  screen line as the actual UART type.

■ If you viewed a file in the File Viewer, then used the online help in
  the File Viewer, the data buffer was not reset properly after exiting
  the online help and returning to the File Viewer ([Down] arrow would
  produce part of the online help, and not the document you were
  viewing).  Fixed.

■ Activating the Ruler (Alt-R) in the File Viewer for the FIRST time,
  worked only every other time.

■ If you've been having problems with OS/2's comm. driver getting
  "stuck" (the terminal just dying on long text displays, such as NEWS
  NS, etc), I think the problem has finally been fixed.  Previously if
  Icom couldn't clear an "interrupt pending" condition on the UART (the
  COM port chip) after 1,000 tries, it would give up assuming the UART
  was broken, and disable interrupt-driven communications: and this is
  why the terminal just died; Icom was no longer processing UART
  interrupts.  For some reason, OS/2's comm. driver (as well as Ray
  Gwinn's comm. driver) doesn't behave quite the same as a real UART
  does, when it comes to clearing interrupts that have already been
  handled.  But regardless I've removed this "broken UART check"
  entirely and the "Stuck" condition should not occur again.  It means
  that if your UART truly IS broken that Icom will hang, but so would
  most other comm. programs on the market... so it's not a big deal.

  Further, Graham Elliott did some extensive testing under OS/2 with
  beta 2, and came up with the following (settings not mentioned below
  should be set to their DEFAULT value):
  --
  DOS Settings which differ from the default:

     DOS_FILES         40
     DOS_HIGH          On
     HW_ROM_TO_RAM     On
     HW_TIMER          On
     IDLE_SENSITIVITY  100

  Now, the critical communication settings appear to be the following...

  For Gwinn's SIO/VSIO drivers:

     SIO_Virtualize_16550_A     On
     SIO_Virtualize_COM_Ports   On
     SIO_Virtual_RTS_is_HS      Off

     Enable 16550 if Found?  .  Yes

  For IBM's COM drivers:

     COM_DIRECT_ACCESS          Off

     Enable 16550 if Found?  .  No

  The "Enable 16550" is in the "Terminal Settings" screen of ICOM's own
  main Setup Menu.
  --
  Using the above settings, Graham was able to use Intellicomm
  successfully at high speed in both OS/2 windowed and full screen
  sessions, with no dropped characters and no "Stuck" terminal
  condition, with both IBM's COM driver and Ray Gwinn's SIO driver.
  Please give these settings a try and let us know how you make out.

ADDED [BETA 2 TO BETA 3]

■ $10.  To Intellicomm's price.  Quite a number of people, since the
  release of beta 1, have expressed the feeling that Icom v2.00 is
  underpriced.  And being one who likes to "know the competition" I did
  know it was underpriced.  It was underpriced intentionally to
  discourage the existing competition, to discourage future competition,
  and to give no one (in the BBS market at any rate) a single excuse to
  buy another product.  But even with the $10 increase, I think I can
  still accomplish these goals.  At $39.95, Icom has only one competitor
  with a lower price, and it's only $5 less.  Paying $5 more for
  Intellicomm, given the feature sets of the two programs, is still
  quite a steal.  And hopefully the extra revenue will allow me, after
  I'm "back in black" again (out of debt), to buy the tools I need for
  future development (the Windows and OS/2 versions) ... and maybe even
  a modem that runs faster than 2400 baud for the upcoming Icom Support
  BBS.  <grin>  Feedback on the new price is welcome.

■ Three new BIF slots have been added, all on the "Logon" screen:

  1. "Press [Escape]" for BBS's with front ends requiring [Esc] to be
     pressed after connecting.
  2. "Enter Birth Date" for those top-security BBS's that feel compelled
     to confirm your birth date from time to time, to make sure you're
     not an IMPOSTER using someone else's account to steal valuable
     national secrets (Sysops get entirely too impressed with their
     BBS's sometimes, don't they?).
  3. "Enter Phone Number" again for the top-security BBS's that confirm
     you really ARE who you claim to be, and not a spy, and ask for your
     voice phone number from time to time, to keep you on your toes.

  Given these new prompts and the 2 new "External Extra" prompts (see
  below) for the first time ever Icom actually has SPARE slots available
  for Wildcat BBS's!  [I await Mustang's next release of Wildcat, which
  will undoubtedly force me to use the empty slots, and probably add
  support for 10 more equally ridiculous prompts... <grin>]

■ All the BIF templates have been updated to support the three new
  prompts mentioned above, and the "spy-prevention questions" have been
  moved from the Extras screen to the new Logon screen slots.  I logged
  on to about 50 BBS's in Toronto to find the most-used "Press [Escape]"
  prompt, and included the winner in all the BIF templates.  But, as
  usual, the front end developers (those responsible for the "Press
  [Escape]" prompt) couldn't see fit to include ANY useable text that
  was common from one type to the next, and we had:

  Press Escape twice for BBS.
  Press [Esc] Twice or wait for BBS.
  Press <Escape> to enter BBS.
  Please press <ESC> to enter BBS
  Please press your Escape key to call Maximus, or wait a few moments.
  Press the ESC key twice to access the BBS.

  Unbelievable, isn't it?  The only common text is "press", and I
  certainly can't use that or Icom would send [Esc] every time the word
  "press" was mentioned in the logon news (and I can't track the prompt
  once and stop watching for it, since some front ends, along with their
  developers, are brain damaged and don't respond the 1st time).

  If I didn't know better (and I don't) I'd swear these guys, and I use
  the term loosely, were intentionally trying to cause you hassles,
  forcing you (and Telix users, and Qmodem users, and anyone else who
  tries to automate logons) to plug different prompts into all your BIFs
  and scripts...  And you know what?  None of these prompts are even
  necessary, nor is the [Esc] key to "identify" you as a human caller.
  The prompts are for front-end mailers (a calling program, to transfer
  network mail), and front-end mail handlers send SPECIAL codes to the
  front-end (the thing that asks you to press [Esc]) to let it know it's
  NOT a human caller -- and if they don't send special codes to identify
  themselves as non-human callers, they bloody well should.  If the
  special codes aren't found, identifying the caller as an automated
  network mail transfer program, the BBS *should* be loaded immediately,
  with no prompts and no [Esc] keys, assuming a human (or Icom, or
  anything BUT a network mail transfer program) is calling.  Is that not
  how anyone with half a brain would design this, to avoid making all
  the HUMAN callers send special codes?  [Oops, must be time for a
  sedative again.  <grin>  BBS Developers... I love 'em all.]

  NOTE: This doesn't mean you *must* use the new prompt slot to handle
  these BBS front ends: a better solution is (and always has been) to
  simply plug this into the BIF "Connect Command" on BIF screen 1:

  ║ Dial Prefix  . . 1                Connect Command  ~~~^[~^[        ║

  ...since this Connect Command is sent immediately after connecting,
  without looking for any idiotic prompts telling you to press [Esc] in
  a hundred different ways.  [The sedative hasn't kicked in yet... gimme
  a minute.  <grin>]  I added the new "Press [Escape]" slot mainly for
  the Icom users who don't read the manual/online help (90% of users, so
  don't feel bad if you're one of them.  Then again, if you're one of
  them, you're not reading this right now either, so ignore that remark
  <grin>).

■ Added the ability to manually purge ALL *untagged* files from a given
  catalog (Noted files are always purged according to the main setup
  "Purge Noted # Days Old" item; if set to 0, Noted files are never
  purged).  Previously records had to be at least 1 day old before you
  could purge them manually.  Now, when you select Tools/Purge from the
  Tagger, you can enter "0" (0 days old) and kill all the untagged
  files.  This new feature may be useful to those who make MULTIPLE new
  files list runs per day: you can read one list, purge all the records
  you've read (they're simply marked as Deleted; but they stay in the
  catalog to eliminate duplicates on the next import), then import
  another list.  Only the files NOT marked as Deleted are the new ones.
  NOTE: You may want to adjust the main setup "Auto Pack when # Purged"
  item on the File Tagger Settings screen up to 1000 records or so
  (maybe even 5000), to avoid an auto-pack after each import.  In fact,
  you may want to set Auto Pack when # Purged to 0 (zero; don't auto-
  pack at all) and simply perform your packs manually, when the time is
  right.

■ Tagger online help, BIF online help, and various other online help
  topics are now complete (still more to go though, so it's not a bug if
  you get a "Help Link not found" error when trying to select a link).

■ Added protocol debugging to ICOM.DBG which shows the filenames
  received, and any status/error messages displayed by the protocol
  (internal protocols only).  This will mainly be of use for my tech.
  support though.

■ SCRIPT STUFFS: Two new commands have been added.  SETCHR and SETCHRS.
  Unless you're already into the v2 script language you won't understand
  this, but the summaries for the commands are:

   SETCHR vTARGET sSOURCE nPOSITION
   SETCHRS vTARGET sSOURCE nPOSITION nMAXCHARS

  Where vTARGET is a variable (containing a string presumably) you wish
  to modify, sSOURCE is the character(s) you want to place in vTARGET,
  nPOSITION is the position in vTARGET to put sSOURCE (0 = the 1st
  character in vTARGET), and nMAXCHARS is the maximum number of
  characters to copy from sSOURCE into vTARGET.  Examples:

   variable s "Print this."
   SETCHR s "!" 10   ;replaces the period with an exclamation mark
   print s           ;displays 'Print this!'

   SETCHRS s "that" 6 4
   print s           ;displays 'Print that!'

  Note that ^@ (NULL; ASCII 0) "terminates" all string variables in the
  script language, so if you continued the above script with this:

   SETCHR s "^@" 5
   print s           ;displays 'Print'

  it would terminate the string at position 5, by storing a NULL after
  the 't' in Print.

■ MORE SCRIPT STUFFS: You can now use variables in GOTO and GOSUB, but
  if you do, you must precede the variable name with an asterisk.
  Examples:

  variable somelabel "a label name"

  goto somelabel   ;looks for/jumps to a label called 'somelabel:'
  goto *somelabel  ;looks for/jumps to a label called 'a_label_name:'

  The first, without an asterisk, causes the script interpreter to take
  the label name literally and look for a label called 'somelabel'...
  and this (as usual) allows you to use the same names for both
  variables AND labels in the same script.  The second, with an
  asterisk, tells the script interpreter to access the CONTENTS of the
  variable 'somelabel', and jump to whatever label name the contents of
  the variable happens to be holding.  Note that this would also be
  quite valid:

  ;SCRIPT1.SCR
  assign GlobalStr[9] "a_label_name"
  script "SCRIPT2.SCR"    ;call another script

  ;SCRIPT2.SCR
  gosub *GlobalStr[9]     ;'gosub a_label_name' is what happens

  What you do with this new ability lies in your imagination.

Beta 2 Notes, 09-03-93
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

STILL UP IN THE AIR DEPARTMENT

■ Online help and SCRIPT.DOC are still incomplete (I knew I should have
  finished them before v2 went into beta... <grin>).  Haven't touched
  the BIF templates since beta 1 either.

■ Some "Key not found" errors were being displayed by the File Tagger
  under various circumstances.  I found the bug that was causing the
  error message, but I'm not positive as yet whether the root of the
  problem was located.  If you run into more problems with the Tagger,
  please re-report with as many details as you can remember as to what
  you did BEFORE the error occurred.

FIXED FROM BETA 1

■ Beta 1 had various installation problems, due to the fact that the
  install routines in ICOM.EXE.  I've moved the installation routines
  into a separate INSTALL.EXE for beta 2, and have tested it on a couple
  of different machines, and it seems to now be working fine.  I
  included *all* the files again for beta 2 though, mainly to re-test
  the installation process.

■ POSTFILE.SCR (a new script included with Icom v2, to virus check and
  otherwise handle newly downloaded files) was not working quite as it
  was supposed to.  The instructions weren't as clear as they could have
  been, and there was a bug in the script itself which all but prevented
  you from doing what you were supposed to do as far as the initial
  setup goes.

  If you would, please give POSTFILE.SCR another shot.  Whether you want
  to use POSTFILE.SCR or not, you should at least know what it's capable
  of doing for you (it can make your file handling a lot easier on new
  downloads, not to mention the auto virus checks, and the script can be
  easily modified to handle all sorts of other things).  It's designed
  so that it'll automatically TELL you what it can do for you, until you
  decide whether you want to use it or not.  The endless loop should not
  be a problem with this POSTFILE.SCR.

■ If you noticed "missing" ICOM.CAP files, and/or lost chains reported
  by CHKDSK with beta 1 (or even lockups, exception 13's or sharing
  violations on Capture File Maintenance), the problem has been fixed.
  If ICOM.CAP was open when the capture file maintenance was performed,
  it was inadvertently LEFT open during the maintenance.  It's a no-no
  to rename an open file.

■ File times were off by four hours on Y/Zmodem downloads.

■ Beta 1 didn't re-initialize the port before dialing or entering
  terminal mode.  If you run a multitasker and keep Icom in memory all
  the time (that's not a good idea by the way, particularly during beta
  testing), and if you ran another comm./FAX program with Icom still in
  memory, beta 1 wouldn't communicate with the port properly the next
  time you used it.  It now re-initializes the port every time it dials
  or enters terminal mode (re-initialize meaning it sets the port for
  interrupt-driven communications, and re-vectors the port interrupts to
  use Icom's interrupt handler).

■ If you had problems with your Tagger catalogs with beta 1, please
  restore your original v1 catalogs from the backup you made before you
  installed v2 (I told you you'd regret it if you didn't make a backup),
  and try again with beta 2.  There was a major bug in beta 1, capable
  of rendering catalogs unreadable.

■ Tagger's "Untag" option left one file noted if you used Untag/Noted.
  Several problems 'could' have popped up with the Untag item other than
  just leaving one file noted... but if you ran into others, they're
  probably fixed now as well.  The way beta 1's Untag was working was
  totally off-base, and it's amazing that anything was untagged at all.

■ Tagger Tools, "Export to Text File" would write garbage all over your
  screen, then lock up the machine.  Fixed.

■ Tagger Tools, "Tagged File Stats" would hang if no files were tagged
  when it was selected.  Feel free to use it at will now (though if you
  use it with no files tagged all you'll get is a report stating that
  nothing is tagged... It's meant to be used only when you DO have files
  tagged and want to know the total bytes D/L time for each BBS).

■ TAGGER.EXE and SETUP.EXE are now properly deleted when v2 is
  installed.  If you haven't already, DELETE these files and don't use
  them again.  ICOM.EXE has them both built in, and the separate .EXE's
  are now obsolete and could destroy your v2 data.  To simulate
  TAGGER.EXE, use:

   ICOM.EXE /CAT:CATNAME /Area:Tagger

■ On installation, "Testing Flow Control" would hang if the CTS line was
  off on the specified COM port.

■ Moving the mouse up/down (forward/backward ... north to south?
  pushing/pulling?, moving towards the front or back of your desk ...?
  I simply don't know how to explain it so I hope you get what I mean
  <grin>) no longer causes various input fields (exiting main setup,
  etc) to cancel.

■ The mouse now remembers to stay off if you shut it off in the main
  setup.

ADDED [BETA 1 TO BETA 2]

■ Something I've been meaning to add for a long time has been
  implemented, though not in a huge way yet: a debugging log.
  \ICOM\CAP\ICOM.DBG (\ICOM\CAP\ being the usual path you use in your
  default Capture File) keeps track of every status/error message Icom
  sends (useful in reporting problems ... the exact wording of an error
  message is important), along with information about automated jobs
  (particularly why a given job task was auto-cancelled ... reply packet
  not found, etc), as well as Tagger import information, when a file is
  excluded from import for some reason (either due to the fact that it
  exists in DOWNLOAD.NDX, or is a duplicate and already exists in the
  catalog, or was excluded due to a user-defined Exclude Keyword).  Lots
  more can and will be done with this log in the future... let me know
  what other sorts of information you'd like to see included, and I'll
  put it on the "to do" list for the year 1995.  <grin>  (I'm rather
  buried in "to do" lists at the moment.)

  NOTE: ICOM.DBG is automatically renamed to ICOM01.DBG every time you
  start ICOM.EXE (after ICOM01.DBG is deleted if it exists).  The file
  should never grow very large, so long as you exit Intellicomm
  periodically ... which is a good idea in any case.  There's no way to
  shut the log off.  As more logging is introduced, a "verbose" level
  will be added, but you'll never be able to shut it off entirely.  It
  was implemented mainly to help with technical support, and it's
  mandatory that you keep the relevant ICOM.DBG file handy after running
  into a problem -- if you need tech. support.  It may also help you to
  narrow some problems down on your own, so make sure you take a peek at
  ICOM.DBG (use "Review Session Captures" from the Main Menu to view it)
  when something goes afoul.

■ You can now use separate "Minimum Connect Speeds" for each BBS (to
  override the Minimum Connect Speed defined in the main setup, and
  allow a lower connect speed on a given BBS), through a new item
  attached to the "Port Settings" item in each BIF.  When you select
  Port Settings you'll be given a second option to set the minimum
  connect speed (set to 300 to allow connects at any speed).  If you set
  a minimum speed, it will show up just after the port settings like so:
  "19200,N,8,1/9600" (the minimum speed follows the '/').  This minimum
  connect speed, if not set to 300, is compared to the CONNECT message
  your modem returns.  If you don't set up a minimum connect speed in
  the BIF, the main setup Minimum Connect Speed (Dialing screen) is
  used, as with v1.  Note that the actual PORT SETTINGS have not
  changed.  The port will be set to whatever speed/data bits/parity/stop
  bits you define in the BIF, as with v1.

■ The Minimum Connect Speed item (main setup/Dialer Settings) has, since
  v1, been allowing re-dialing right up to the Max. Dial Attempts item
  defined in the BIF (forever if no Max. Dial Attempts was set).  During
  automated runs, it now untags the BIF after 3 unsuccessful connects,
  at a lower speed than the Minimum Connect Speed.  During manual
  dialing (Dial from the BBS Directory), the BIF remains tagged right up
  to the Max. Dial Attempts, as with previous versions.

  This is only relevant to those who use the Minimum Connect Speed
  feature: if you have the minimum speed set to 300 baud, Icom will
  allow connections at any speed.

■ Some general information and debugging information has been added to
  the Port Settings menu ([Alt-P] from Terminal mode).  It shows the
  UART type detected (16550 or 8250), and the on/off state of the CTS,
  RTS, DSR, and DTR lines.  [Clear to Send, Request to Send, Data Set
  Ready, and Data Terminal Ready.]  If you notice anything "funny" with
  the terminal, such as characters you type aren't being sent, or
  nothing is displayed on the screen from the BBS, check this menu to
  see if one of the flow control flags is stuck.  [Particularly in OS/2,
  since we've had some problems with things being "stuck".]  If
  something is stuck, open the "Port" menu, hilight the port and press
  [Enter].  That should reset everything.  [Er, until you look at the
  menu when your port is operating properly, you mightn't have a clue
  what it should look like when everything is fine.  You might want to
  enter terminal mode and make a note for future use.]

■ Added /CAT:CATNAME command line switch (where CATNAME is the name of a
  File Tagger Catalog), for use with the /Area:Tagger switch.  To view
  the FILELIST catalog without initializing your modem or entering Icom
  itself, use the command:

   ICOM /CAT:FILELIST /Area:Tagger

■ Tagger Tools/"Export to Text File" now allows you to export All files
  in a catalog, only Tagged files, only Noted files, both Tagged and
  Noted, or just the Untagged files.  This applies to the script CEXPORT
  command as well.  The CEXPORT command has been revised to take a
  numeric parameter signifying the export type:

  CEXPORT [sBIFNAME] [sTEXTFILE] [nEXPORTTYPE] [nNODISPLAY]

  [See SCRIPT.DOC for a full explanation of CEXPORT.]  nEXPORTTYPE is an
  optional number from 1 to 5, which controls the TYPE of files that are
  exported:

   1 = All files (Noted, Tagged and Untagged).
   2 = Tagged files only.
   3 = Noted files only.
   4 = Tagged or Noted files only.
   5 = Untagged files only.

  If nEXPORTTYPE is omitted (or 0), the user is prompted for the type of
  files to export.

■ Something I forgot to document in the beta 1 UPGRADE.DOC: "Find/Save
  Bookmark" has been added to the Tagger Tools menu.  You can use it to
  save and restore a given position in the catalog WITHOUT leaving the
  catalog.  Icom v1 had bookmarks, but it only saved it when you exited
  the catalog.  With Find/Save bookmark, you can save your position, go
  somewhere else to do something, then restore your original position
  without having to use "Find" and remember a filename.

■ I also forgot to mention this in the beta 1 UPGRADE.DOC (no need to
  read that file again for beta 2 by the way, everything new is covered
  here), but you can now use script commands in BIF prompt responses,
  and in job Custom Commands, by preceding the command with '&'.
  Example:

  ║ 12  Custom Command/Run script        │   CC: &WAITFOR "Some text" ║

  The most likely commands you'll use will be &WAITFOR, or perhaps
  &DOWNLOAD or &UPLOAD, etc.  Since Custom Commands can be grouped one
  after the other to handle multiple BBS commands/menus, you can pretty
  well build a workable script right in your jobs, with Custom Commands,
  instead of having to keep an external script on-disk.  BIF responses
  can also handle single script commands in the same manner, but I have
  yet to figure out what use this will be (it was simple to do since BIF
  responses use the same routine as Custom Commands do, so the BIF
  support was automatic.... maybe you can figure out a use for it in a
  BIF, perhaps in one of the "Extra" prompt slots).

■ Tagger browse mode/bottom window now displays the description color in
  the Bold/Hotkey color by default.  In autobrowse mode, lines are
  changed to the Unselected/Background color.

Beta 1 Notes, 08-08-93
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
■ Still incomplete: The online help is not fully complete yet, nor is
  SCRIPT.DOC.  I'll also be working on a few more BIF templates between
  now and the release if time permits.

BETA INFORMATION
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Questions & Answers
Q. What is a "beta" release?
A. Beta releases are preliminary releases to be used voluntarily by a
   group of people who are interested in a given product.  The purpose
   of beta testing computer software is to expose the product to a wide
   variety of hardware under a wide variety of circumstances, and to
   obtain user feedback and incompatibility/bug reports.
Q. How much does it pay?
A. Aside from my gratitude, and the advantage of getting to know and use
   the product ahead of everyone else, nothing (this is the case with
   most all software products, if not all).  Beta testers volunteer
   because they're interested in the product and want to check out the
   new features, and also want to help to ensure that the product
   succeeds so it doesn't flop on its face and disappear three months
   down the road.  Normally only devoted users do the beta testing and
   if you're not a devoted Intellicomm user you should probably delete
   this beta release and wait for the general release.  Beta testing
   (running into bugs) can be frustrating and I don't want to lose your
   interest before I even get the general release out.  And that may
   well happen if you aren't a devoted user.
Q. Should I register the beta, or wait for the general release?
A. As with everything in user-supported software, it's really up to you.
   The problem is that if you "wait" until Icom is 100% bug free (if
   that day ever comes... Windows, WordPerfect, Lotus, DOS, etc., aren't
   bug free, but you pay for them first and find the bugs later), I
   won't be able to pay the bills WHILE I'm working on fixing whatever
   problems you run into.  By purchasing Intellicomm, you're ensuring
   that I'll be able to spend time on it.  If you hold onto your money
   waiting, you're helping to ensure that I'll be forced to find another
   job to pay my bills... taking time away from Icom, and taking time
   away from the bug fixing.  I've been developing user-supported
   software for five years now, I plan to be doing it in another five
   years, and I'm not about to take your money, leave you in the lurch,
   and run off to Mexico with it.  <grin>  If you make the purchase,
   you're allowing me to spend the time on Intellicomm, instead of
   spending time working for someone else to pay my bills (which I've
   had to do several times in the last few months, and may have to again
   soon).
Q. Can I re-distribute beta releases?
A. Not yet, and please take this seriously and refrain from giving
   copies of this beta release to ANYONE.  The first couple of beta
   releases are bound to have bugs, and the idea is to work out any bugs
   or incompatibilities BEFORE the general public gets the product.  As
   soon as it looks fairly stable I'll be distributing it more widely,
   and a release notice will be posted in the usual tech. support areas
   at that time.  THEN you can feel free to re-distribute it (with
   thanks!).
Q. Can I talk about it?
A. Yes!  You can discuss anything at all about Icom v2, in public e-mail
   messages, in any conference, to anyone you like.  And of course, the
   whole idea of beta testing is to work the bugs out ... so if you find
   a problem, drop me a line (Wayne Duff) in a NorthAmeriNet or RIME
   Intellicomm/Liberator conference.  Please keep bug reports limited to
   the Intellicomm conferences during the beta testing.

Press [Esc] to exit.